Method, and arrangement in a communications network

ABSTRACT

A method and an arrangement in a data communications system. The object of the invention is to achieve a wireless communication between a processing unit and a printer using a safe transmission and an increased transmission range compared to the infrared transmission. The solution is a way of printing a document in a data communications system using a protocol profiled for printing in the Bluetooth protocol architecture.

[0001] This application claims the benefit of U.S. provisionalapplication No. 60/208,098, filed May 31, 2000.

FIELD OF INVENTION

[0002] The present invention relates to a method and an arrangement in adata communications system according to the preambles of the independentclaims. More specifically it relates to a processing unit wirelesslyconnected to a printer. It further relates to printing a document bymeans of the printer, the printer being controlled by the processingunit.

DESCRIPTION OF RELATED ART

[0003] Processing units, e.g. PC's requiring to print documents usestypically a printer. A processing unit and a printer are generallycommunicating with each other through cables. But communicationdisruption caused by wire breakage or inadequate securing of the cableends, added cost of providing a reliable cable and reliable associatedconnectors, tangling of the cables and requirements of flexibility, etc.leads to a requirement of replacing the cables.

[0004] A way of communicating, using a infrared link instead of a cableis shown in the American patent U.S. Pat. No. 6,055,062, which disclosesan electronic printer having an attached accessory unit. The accessoryunit handles e.g. optional media (e.g. paper) supply units and optionalmedia output. To communicate with the accessory unit, the printer uses atwo-ways infrared communications connection to the accessory unit towhich it is immediately adjacent.

[0005] However the range of the infrared link is short, so that thedistance between processing unit and the printer have to be less than afew meters and there must be a clear line of sight between them.

[0006] The so-called Bluetooth interface is an example of a modern radiointerface, which was originally intended as replacement for cablesbetween units. The term Bluetooth is in this disclosure used as anexample of usage of short-range radio communication. By replacing thecables, the short-range radio technology provides a universal bridge toexisting data networks, a peripheral interface, and a mechanism to formsmall private ad hoc groupings of connected devices away from fixednetwork infrastructures or connected to a fixed network infrastructurevia a gateway. Designed to operate in a noisy frequency environment, theBluetooth radio uses a fast acknowledgement and frequency hopping schemeto make the link robust. Bluetooth radio modules avoid interference fromother signals by hopping to a new frequency after transmitting orreceiving a data packet, as shown in FIG. 1 wherein the X-axisrepresents the frequency f and the Y-axis represents the time t.Compared with other systems operating in the same frequency band, theBluetooth radio typically hops faster and uses shorter radio packets.This makes Bluetooth radio more robust than other systems. Use ofForward Error Correction (FEC) limits the impact of random noise onlong-distance links.

[0007] Bluetooth radio is a wireless communication technology using afrequency-hopping scheme in the unlicensed Industrial Scientific Medical(ISM) band at 2.4 GHz. A frequency hop transceiver is applied to combatinterference and fading. A shaped, binary FM modulation is applied tominimise transceiver complexity. The gross data rate is 1 Mb/s andTime-Division Duplex (TDD) scheme is used for full duplex transmission.

[0008] The Bluetooth protocol is a combination of circuit and packetswitching. In FIG. 1, S1 denotes one time slot, and P1 denotes a packetcovering three time slots. A time slot is 0,625 ms long. Time slots canbe reserved for synchronous packets. Each packet is normally transmittedin a different hope frequency. A packet normally covers a single slot,but can be extended to cover up to five slots. Bluetooth can support anasynchronous data channel, up to three simultaneous synchronous voicechannels, or a channel with simultaneously supports asynchronous dataand synchronous voice. Each voice channel supports 64 kb/s synchronous(voice) link. The asynchronous channel can support an asymmetric link ofmaximally 721 kb/s in either direction while permitting 57,6 kb/s in thereturn direction, or a 432,6 kb/s symmetric link.

[0009] In FIG. 2, the different function blocks of a system usingshort-range radio transceivers such as Bluetooth are shown. A radio unit201 is connected to a link control unit 202 providing the base band. Thelink control unit 202 is connected to the Central Processing Unit,called CPU, 203 providing the link management. The CPU is connected tothe memory 204 providing software functions and consisting of two memoryunits: a SRAM 205 and a FLASH 206. The CPU 203 is connected to a hostinterface 207. A SRAM is a fast temporary memory. FLASH is aprogrammable ROM.

[0010] Two or more, up to eight Bluetooth units sharing the same channelform a piconet, i.e. a piconet is a collection of devices connected viaBluetooth technology in an ad hoc fashion. Within a piconet a Bluetoothunit can have either of two roles: master or slave. Within each piconetthere may be one and only one master, and up to seven active slaves,i.e. a piconet starts with two connected devices, such as a portable PCand a cellular telephone, and may grow to eight connected devices. AllBluetooth devices are peer units and have identical implementations. AnyBluetooth unit can become master in a piconet. A master unit is thedevice in a piconet whose clock and hopping sequence are used tosynchronise all other devices within the piconet. A slave unit is everydevice in a piconet that is not a master.

[0011] The communication within a piconet is organised such that themaster polls each slave according to some polling scheme.Master-to-slave transmission always starts in an even-numbered time-slotwhile slave-to-master transmission always starts in an odd-numbered timeslot. With one exception the slave is only allowed to transmit afterhave been polled by the master. The slave then starts its transmissionin a slave-to-master time slot immediately following the packet receivedfrom the master. The master may or may not include data in the packetsused to poll the slave. The only exception to the above principle isthat when a slave has an established Synchronous Connection Oriented(SCO) link, the slave is always allowed to transmit in the pre-allocatedslave-to-master slot, even if not explicitly polled by the master in thepreceding master-to slave slot. The term SCO-link will be disclosed inmore details below. In a Bluetooth communications system there is nodirect transmission between slaves in a piconet.

[0012] The Bluetooth protocol stack will be described, according to thespecifications of the Bluetooth system. The protocol stack which isdepicted in FIG. 3, includes two Bluetooth units 301 and 302. In thefigure the physical layer and the data link layer are shown.

Baseband BB

[0013] The base band describes the digital signal processing part of thehardware, i.e. the Bluetooth link controller, which carries theBluetooth protocols and other low-level link routines. The Basebandresides in the physical layer 301 and the data link layer 304. Thebaseband specification defines two link types: SynchronousConnection-Oriented (SCO) links and Asynchronous Connection-Less (ACL)links. SCO links support real-time voice traffic using reservedbandwidth. ACL links support best effort traffic.

Link Manager Protocol LMP

[0014] LMP handles messages used for link set-up, security and control.LMP is layered over the Baseband protocol and resides in the data linklayer 304.

Logical Link Control and Adaptation layer Protocol, L2CAP

[0015] L2CAP is also layered over the Baseband protocol and resides inthe data link layer 304. L2CAP provides connection oriented andconnectionless data services to upper layer protocols with multiplexingcapability, segmentation and reassemble operation, and groupabstractions. The L2CAP Specification is only defined for ACL links.

Network Layer 305

[0016] The network layer is currently not specified in the Bluetoothstandard.

High Level Protocol or Application 306

[0017] Device information, services and the characteristics of theservices can be queried using the Service Discovery Protocol SDP. LikeSDP, RFCOMM is layered on top of the L2CAP. RFCOMM is the ‘cablereplacement’ protocol, which provides transport capabilities forhigh-level services (e.g. OBEX protocol) that use serial line as thetransport mechanism.

[0018] On top of the link and transport protocols, the applicationsstill need some specific protocols to complete the protocol stack. Inthe Bluetooth architecture, the application-specific protocols are addedon top of RFCOMM or directly on the L2CAP. L2CAP can only be accessedvia a protocol which is supported by a Bluetooth profile such as RFCOMM.

[0019] The enumerated application-specific protocols offer the basicfunctionality in the Bluetooth environment and they provide only thecable-replacement capabilities. Features such as broadcasting,point-to-multipoint topologies, and scatternet possibilities are notreally utilised by these current high-level protocols and usage models.Thus, there are numerous possibilities for developers to create moreapplications, the nature of which can be totally different from theexisting ones.

[0020] The object of the present invention is to achieve a wirelesscommunication between a processing unit and a printer using a safetransmission and an increased transmission range compared to theinfrared transmission used in the above mentioned U.S. patent.

SUMMARY OF THE INVENTION

[0021] The object of the invention is to unravel the above mentioneddrawbacks and achieve a way of printing a document in a datacommunications system using a protocol profiled for printing in theBluetooth protocol architecture.

[0022] This is achieved according to the method and arrangement setforth in the characterising parts of the independent claims.

[0023] Preferred embodiments are set forth in the independent claims.

[0024] An advantage of the method and arrangement according to thepresent invention is that it is possible to communicate wirelessly witha printer at a wide range, up to 10 meters and extendable up to 100meters.

[0025] Another advantage is that it offers a safe transferring of data.

[0026] Yet another advantage is that the present invention makes itpossible to wirelessly select a printer among available printers.

BRIEF DESCRIPTION OF THE DRAWINGS

[0027]FIG. 1 is a diagram showing the relationship between timeslots andfrequency hops in a system using Bluetooth.

[0028]FIG. 2 is a diagram illustrating the different function blocks ofa Bluetooth system.

[0029]FIG. 3 is a diagram showing the Bluetooth protocol stack.

[0030]FIG. 4 is a schematic block diagram showing a communicationssystem according to the present invention.

[0031]FIG. 5 is a schematic block diagram showing an entity according tothe present invention.

[0032]FIG. 6 is a schematic block diagram showing a printer entityaccording to the present invention.

[0033]FIG. 7 shows a flowchart of the method according to the invention.

[0034]FIG. 8 is a bloc diagram depicting a protocol overview over theBluetooth protocols according to the invention.

[0035]FIG. 9 shows a signalling sequence over a typical SDP transaction.

[0036]FIG. 10 shows a signalling sequence over typical WPP transactions.

[0037]FIG. 11 shows a signalling sequence over typical WPP transactions.

[0038]FIG. 12 shows a signalling sequence over typical WPP transactions.

[0039]FIG. 13 shows a signalling sequence over typical WPP transactions.

[0040]FIG. 14 shows a signalling sequence over typical WPP transactions.

[0041]FIG. 15 shows a signalling sequence over typical WPP transactions.

DESCRIPTION OF PREFERRED EMBODIMENTS

[0042] FIGS. 1-3 are related to prior art and described above under“Description of related art”.

[0043] The wording “client” is in this disclosure defined as the entitysending a request, and the wording “server”, is in this disclosuredefined as the entity receiving a request.

[0044]FIG. 4 shows a possible scenario of the present invention. ABluetooth data communications system 401 includes two nodes whereof oneis a processing unit, which in this example is a PC 402 and the other isa printer 403. A wireless printer protocol according to the invention isimplemented in the Bluetooth protocol stack which is included in aentity, e.g. a PC-card 404, connected to or implemented in the PC 402,and in a printer entity, e.g. a printer adapter 405, connected to orimplemented in the printer 403. According to the Bluetooth standard thedistance between the processing unit and the printer is up to 10 metersand extendable up to 100 meters The printer adapter 405 might beconnected to the printer port on the printer. The PC 402 and the printer403 are connected to each other via a Bluetooth air interface 406. Bothentities 404 and 405 comprise a respective computer, each computercomprising an internal memory for storing computer program not visiblein FIG. 4.

[0045] The entity 404 connected to or implemented in the processing unit402, will now be described more in detail. The entity, now referred toas 501 is shown in FIG. 5. The entity 501 includes a Bluetooth protocolstack in which protocol stack a wireless printer protocol isimplemented. The printer protocol comprises a printer client whichcommunicates with a printer server by means of the wireless printerprotocol, the Bluetooth protocol stack and air interface,. The printerserver is included in a printer but is not visible in FIG. 5.

[0046] The entity 501 includes an establishing device 502 arranged forestablishing a bi-directional wireless ACL connection between theprocessing unit and the printer by means of the Bluetooth protocol.

[0047] The entity 501 comprises further a sending device 503 arrangedfor sending a connection request message to the printer server and anegotiating device 504 arranged for negotiating configuration parameterswith the printer server. The negotiating device 504 comprises a sendingdevice 505 arranged for sending, to the printer server, a configurationrequest message including no new options if the printer client usesdefault values. The negotiating device 504 comprises also a sendingdevice 506 arranged for sending, to the printer server, a configurationrequest message including a suggestion of configuration options. Thenegotiating device 504 comprises further a sending device 507 arrangedfor sending, to the printer server, a further configuration requestmessage including a suggestion of configuration options which differsfrom earlier suggestions of configuration options. This latter sendingdevice 507 is to be used if the printer client receives a responsemessage from the printer server that the configuration request was notacceptable due to e.g. unacceptable parameters, unknown option etc.

[0048] The entity 501 comprises a sending device 508 arranged forsending a set attribute request message to the printer server, themessage comprising e.g. a coding table concerning a negotiated codingtype and is to be loaded by the printer server.

[0049] The entity 501 comprises a sending device 509 arranged forsending keep alive messages frequently to the printer server. A keepalive timer 510 is implemented in the entity 501 and comprises astarting device 511 arranged for starting and restarting the keep alivetimer 510 each time a valid message is sent to the printer server andeach time a valid message is received from the printer server. The keepalive timer 510 further comprises a closing device 512 arranged forclosing the connection between to the printer server, when the keepalive timer 510 expires.

[0050] For starting one or more printjobs the entity 501 comprises astarting device 513 arranged which starting device 513 comprises asending device 514 arranged for sending a request message to the printerserver comprising a request to start a printjob.

[0051] The print data that is to be printed by the printer is sent bymeans of a sending device 515 arranged for sending the print data to theprinter server. Said device 515 includes a sending device 516 arrangedfor sending a number of request messages to the printer server, themessages comprising print data.

[0052] A printing process might be broken, e.g. because the printer runsout of paper or the ACL connection is broken, etc. This is reported bythe printer server in a message received by the printer client. Theentity 501 comprises a device 527 arranged for interpret the message andgive a note to the user of the processing unit, e.g. by presenting thenote on the screen of the PC.

[0053] E.g. a refill of paper or a new creation of a disconnected ACLconnection might make, but the entity 501 comprises a continuing device517 arranged for continuing the printing process by continuing to sendprint data request messages to the printer server, starting with theprint data subsequent to a last received print data acknowledgementmessage.

[0054] The entity 501 comprises a stopping device 518 arranged forstopping the keep alive timer 510 when an ACL connection is disconnectedduring a printing process.

[0055] The entity 501 further comprises a requesting device 519 arrangedfor requesting a reconnection of a session defined by the sessionidentifier in a message sent to the printer server to be used when a newACL connection is created to the printer, after a break.

[0056] The entity 501 comprises a stopping device 520 arranged forstopping the print job said stopping device 520 comprises a sendingdevice 521 arranged for sending a message to the printer server, themessage comprising a request to stop the printjob. The stopping device520 will be used when all data to be printed in a printjob is sent tothe printer.

[0057] The entity 501 further comprises a closing device 522 arrangedfor closing the connection between the processing unit and the printer,the closing device comprising a sending device 523 arranged for sendinga message to the printer server, the message comprising a request todisconnect a session identified by a session identity.

[0058] The entity 501 comprises a stopping device 524 arranged forstopping the sending of keep alive messages after closing a connectionbetween the printer client and the printer server.

[0059] The entity also comprises a receiver 525 for receiving messagessent from a printer and a transmitter 526 for sending messages to theprinter.

[0060] The printer entity 405 connected to or implemented in the printer403 shown in FIG. 4, will now be described more in detail. The printerentity, now referred to as 601 is shown in FIG. 6. The printer entity601, including a Bluetooth protocol stack in which a wireless printerprotocol is implemented, said protocol comprising a printer server whichcommunicates, by means of the wireless printer protocol, the Bluetoothprotocol stack and air interface, with a printer client, e.g. theprinter client in the entity 501 described above . The printer client isincluded in a processing unit 402 and is not visible in FIG. 6.

[0061] The printer entity 601 comprises a receiver 602 for receivingmessages sent from a processing unit and a transmitter 603 for sendingmessages to the processing unit.

[0062] The printer entity 601 further comprises a responding device 604arranged for responding upon a connection request whether the connectionis successful or not, in a response message sent to the printer client.

[0063] The printer entity 601 comprises a negotiating device 605arranged for negotiating configuration parameters with the printerclient within the processing unit.

[0064] The negotiating device 605 comprises a responding device 606arranged for responding upon a configuration request whether theconfiguration options in the configuration request are supported by theprinter server or not.

[0065] The negotiating device 605 comprises a loading device 607arranged for loading a coding table or other optional attributes sentfrom the printer client.

[0066] The negotiating device 605 further comprises a sending device 608arranged for sending a response, whether the loading of the coding tablewas successful or not, to the printer client. The printer entity 601comprises a sending device 609 arranged for sending keep alive messagesfrequently to the printer client.

[0067] A keep alive timer 610 is implemented in the printer serverwithin the printer entity 601. The printer entity 601 comprises astarting and restarting device 611 arranged for starting the keep alivetimer each time a valid message is received from the printer client andeach time a valid message is sent to the printer client.

[0068] The printer entity 601 comprises a starting device 612 arrangedfor starting a print job. The starting device 612 comprises a confirmingdevice 613 arranged for confirming a start printjob request message sentto the printer client

[0069] The printer entity 601 comprises a receiving device 614 arrangedfor receiving print data from the printer client. The receiving device614 including a sending device 615 arranged for sending anacknowledgement message to the printer client after receiving a previousdecided number of print data request messages.

[0070] The printer entity 601 comprises an indicating device 616arranged for indicating, in a message sent to the printer client, thatthe printer has reported an exemption condition, e.g. that the printeris out of paper, if the printer runs out of paper.

[0071] The printer entity 601 further comprises an indicating device 617arranged for indicating, in a message sent to the printer client, whenthe printer clears the exemption, e.g. that the printer is refilled,when the printer is refilled.

[0072] The printer entity 601 comprises a stopping device 618 arrangedfor stopping the keep alive timer when an ACL connection to theprocessing unit is disconnected during a printing process.

[0073] The printer entity 601 comprises a sending device 619 arrangedfor sending a response message to the printer client, according towhether a reconnection request is granted or not.

[0074] The printer entity 601 comprises a stopping device 620 arrangedfor stopping the print job. The

[0075] stopping device 620 including a sending device 621 arranged forsending a response message, after the printer server has received arequest to stop the printjob, the message comprising a confirmation thatthis is apprehended and is sent to the printer client.

[0076] The printer entity 601 comprises a sending device 622 arrangedfor sending a response message to the printer client, according towhether a disconnection request is granted or not.

[0077] The printer entity 601 further comprises a stopping device 623for stopping the sending of keep alive messages after the connection tothe printer client is closed.

[0078]FIG. 7 shows a flowchart of a possible scenario of the printingprocess according to the present invention.

[0079] The method includes the following steps:

[0080]701. A bi-directional wireless Asynchronous Connection-Less (ACL)connection is established between the processing unit 402 and theprinter 403 by means of the printer protocol calling the L2CAPrequesting the connection and the L2CAP creating the connection.

[0081]702. A connection is established between the printer client andthe printer server for one or more printjobs.

[0082]703. The processing unit 402 and the printer 403 negotiateconfiguration parameters for said connection.

[0083]704. Keep alive messages are sent frequently during the sessionfrom the processing unit 402 to the printer 403 and from the printer 403to the processing unit 402.

[0084]705. The processing unit 402 starts the printjob and

[0085]706. sends the printer data to the printer 403.

[0086]707. The print job is stopped and

[0087]708. the connection is closed between the processing unit 402 andthe printer 403.

[0088] The method is implemented by means of a computer program productcomprising the software code portions for performing the steps of themethod. The computer program product is run on a computer stored in adigital computer within the process unit 402 and within the printer 403,e.g. in the printer adapter 405.

[0089] The computer program is loaded directly or from a computer usablemedium, such as floppy-disc, CD, Internet etc.

[0090]FIG. 8 is a bloc diagram depicting a protocol overview over theBluetooth protocols including the wireless printer protocol WPPaccording to the invention. The left side represents the PC 801 and theright side represents the Printer 802. The Host Control Interface HCI ismarked as a horizontal line. The HCI provides a command interface to thebaseband controller, link manager, and access to hardware status andcontrol registers. SDP, L2CAP and LMP are described above, under RelatedArt. WPP will be described more in detail below.

[0091] The interface between two entities on the same layer, a so-calledhorizontal interface, is defined by it's protocol 803, 804, 805 and 812,e.g. L2CAP on PC communicates with L2CAP on printer using the L2CAPprotocol.

[0092] The actual flow of data (Protocol Data Units, PDU:s) is donebetween entities in different layers 806, 807, 808, 809, 810 and 811, aso-called vertical interface.

[0093] On the PC side the protocols is implemented by followingapplications:

[0094] Client L2CA Application implements L2CAP

[0095] Client Printer Application implements WPP

[0096] Client Discovery Application implements SDP

[0097] On the printer side the protocols is implemented by followingapplications:

[0098] Server L2CA Application implements L2CAP.

[0099] Server Printer Application implements WPP.

[0100] Server Discovery Application implements SDP.

[0101] The printing method according to the invention will now bedescribed more in detail.

[0102] A processing unit requires to print a document, i.e. to perform aprintjob, by means of a printer.

[0103] The processing unit wishes to know which printers that areavailable, and select one of them, therefore the printing process startswith the Device Discovery procedure, which is a procedure known from theart. FIG. 9 shows a sequence diagram of a typical SDP transactionbetween the Client Discovery Application 901 and the Server DiscoveryApplication 902. It is assumed that inquire has been performed. As aresult of inquire the class of device is retrieved. Class of deviceindicates the type of device and which type of services the devicesupports. It is also assumed that a point to point connection with theserver has been established, using L2CAP. The PrinterServiceClassId isrepresented as a Universally Unique Identifier (UUID) and is known byclient discovery application.

[0104] A message, e.g. a denoted SDP_ServiceSearchReq message 903 issent, from Client to Server, to ask which services, in this caseprinters that are available. The server returns service records handlesassociated with the respective available printers, e.g. in a denoted SDPServiceSearchRsp message 904.

[0105] The printer service record database serves as a repository ofdiscovery-related information. All of the information about a servicethat is maintained by an SDP server is contained in a single servicerecord. The service record consists entirely of a list of attributes. Aservice record handle uniquely identifies each service record within theSDP server, according to Service Discovery Protocol, BluetoothSpecification version 1.0 B concerning SDP and Appendix VIII, BluetoothAssigned Numbers, Bluetooth Specification version 1.0 B concerningassigned numbers for predefined attributes and their identity.

[0106] The Client selects one of the available printers and requests forits attributes, e.g. the address of the printer, a in a message, e.g. adenoted SDP_ServiceAttributeReq message 905 using the service recordhandle. The attributes are returned in one or more messages, e.g.denoted SDP_ServiceAttributeRsp messages 906.

[0107] The Client stores the received attributes and terminate the L2CAPconnection

[0108] A bi-directional wireless asynchronous connection-less (ACL)connection is established (701) between the processing unit and theprinter. This is achieved by means of the printer protocol in theprocessing unit calling the L2CAP in the within the same unit,requesting the connection to the printer. The printer is connected e.g.by means of the printer address being one of the attributes received.The L2CAP creates the connection and notifies the created connection theprinter protocol.

[0109]FIG. 10 shows sequence diagrams of a typical WPP transactionsconcerning the connection operations between the WPP Client 1001 and theWPP Server 1002, according to the invention

[0110] A creation of a session between a client printer application(source) and a server printer application (destination) is to berequested, i.e. for establishing a connection for one or more printjobs.This is performed by sending a message, e.g. a denotedWPP_Connection_Req message 1003, from the WPP client 1001 to the WPPserver 1002. This is shown in FIG. 10. A status indication to the clientprinter application whether the connection was successful or not andmaking the session valid if successful is required. This is be performedin a message by the WPP server 1002, e.g. in a denotedWPP_Connection_Rsp message 1004, also shown in FIG. 10. This messagealso includes a session identity.

[0111] The next step of the printing process is the WPP negotiationprocedure according to the invention. FIGS. 11 a-cand 12 shows sequencediagrams of a typical WPP transactions concerning the negotiationoperations between the WPP Client 1001 and the WPP Server 1002,according to the invention.

[0112] After creating the session a configuration of the WPP server 1002is required. Examples of configuration options are e.g. the number ofprint data request messages to be received by the printer before returna confirmation message, coding type and table size.

[0113]FIGS. 11a, b and c shows three different sub-scenarios of asuccessful negotiation of a coding type for data compression. A message,e.g. a denoted WPP_Configuration_Req message, is sent from the WPPclient 1001 to WPP server 1002 to establish an initial logical linktransmission contract between the WPP client 1001 and WPP server 1002and to negotiate configuration parameters, e.g. the coding type. In thisexample the WPP server 1002 supports the coding types hamming, tablesize=80 (default) and huffman table size=80. The three respectivesub-scenarios may be a continuation of the connection scenario in FIG.10.

[0114] In the first sub-scenario, shown in FIG. 11a, the WPP client 1001uses default values, i.e. hamming, table size=80 and accordingly theWPP_Configuration_Req message 1101 sent, from the WPP client 1001 to theWPP server 1002, includes no new options. Since that is a coding typethat the WPP server 1002 supports, it responses success in a message,e.g. a denoted WPP_Configuration_Rsp message 1102.

[0115]FIG. 11b shows the second sub-scenario in which the WPP client1001 requests the WPP server 1002, in message, e.g. a denotedWPP_Configuration_Req message, if hamming, table size=100 can be used1103. This is not a coding type that the WPP server 1002 supports andaccordingly it responses in a message, e.g. a denotedWPP_Configuration_Rsp message 1104, failure and suggests that hamming,table size=80 can be used. The WPP client 1001 supports also hamming,table size=80 and responses this to the WPP server 1002 in a message,e.g. a denoted WPP_Configuration_Req message 1105. The WPP serverresponses success in a message, e.g. a denoted WPP_Configuration_Rspmessage 1106.

[0116] In the third scenario, shown in FIG. 11c, the WPP client 1001suggests an coding type which is unknown for the printer, i.e. a codingtype not supported by the printer, and a size=100, in a message, e.g. adenoted WPP_Configuration_Req message, sent 1107 to the WPP server 1002.Since this coding type is unknown for the WPP server 1002, it responsesin a message, e.g. a denoted WPP_Configuration_Rsp message 1108 failureand that the coding type is unknown. The WPP client 1001 then triesanother coding type that it supports, in this example huffman, size=80,in a subsequent message, e.g. a denoted WPP_Configuration_Req message1109 sent to the WPP server 1002. The WPP server 1002 supports huffman,size=80 and accordingly it responses success and confirms huffman,size=80 in a message, e.g. a denoted WPP_Configuration_Rsp message thatis sent 1110 to the WPP client 1001.

[0117] After the configuration negotiation of coding type according toe.g. the scenarios depicted in FIGS. 11a-c, the WPP client 1001 requeststo set an attribute which is illustrated in FIG. 12. The WPP client 1001sends a coding table concerning the negotiated coding type in a message,e.g. a denoted WPP_Set_Attribute_Reg message sent 1201 to the WPP server1002. The WPP server loads the coding table to be used and confirmswhether it was successful or failure in a message, e.g. a denotedWPP_Set Attribute_Rsp message 1202 sent to the WPP client 1001.

[0118] The next step of the printing process is the WPP printingprocedure. FIGS. 13a-d, 14 and 15 shows sequence diagrams of a typicalWPP transactions concerning the printing operations, between the WPPclient 1001 and the WPP server 1002, according to the invention.

[0119]FIGS. 13a-dshows a first sub-scenario of a successful printing ofone print job. FIG. 13a shows the procedure for sending keep alivemessages.

[0120] When the connection has been established and negotiation has beenperformed, keep alive messages are to be sent, by the WPP client 1001,1303 and WPP server 1002, 1304, frequently, e.g. once each 5 second, asan indication that the source is up and running. Such a message is adenoted WPP_Keep_Alive message. If a break occurs when printing, theprinter will find out that, since it does not receive any more keepalive messages. The printer then terminates the printjob and can letother users in. A break can also occur on the printer side. There isalso occasions when the printer or processing unit are hard loaded,sending keep alive messages just to tell the receiver that it stillalive but it goes slowly at the moment. When a connection has beendisconnected by WPP client, WPP client 1001 and WPP server 1002 shallstop sending denoted WPP_Keep_Alive messages.

[0121] A WPP Keep Alive Timer is restarted each time a valid message isreceived from the remote endpoint. The timer is implemented on bothclient and server side. If the Keep Alive timer expires the remoteendpoint is considered faulty and the connection is closed and higherlevel applications is notified. The Keep Alive Timer shall be stoppedwhen a link is disconnected and restarted when a new link is establishedwith the remote endpoint. If a new link is established within areasonable time, e.g. 10 seconds, the printjob continues where broken.Each WPP message will trigger a restart of a WPP timer.

[0122] In FIG. 13b a start of a printjob and sending of data to beprinted is shown. The WPP client 1001 requests the WPP server 1002 tostart a printjob in a denoted WPP_Start_Print_Req message 1305 s, whichin turn confirmed by the WPP server (1002) in a denotedWPP_Start_Print_Cfm message 1306. The WPP client then requests the WPPserver 1002 to print data included in a number of denotedWPP_Print_Data_Req messages 1307, 1308. A confirmation is to be sentafter the WPP server 1002 has received a number N WPP_Print_Data_Reqmessages 1307, 1308. The value of N is negotiated during configuratione.g. N=4. The acknowledgement is e.g. sent in a denotedWPP_Print_Data_Ack message 1309. This procedure goes on until all datato be printed is received by the printer server. I.e. until the lastWPP_Print_Data_Req message 1310 is received.

[0123] When all data to be printed is sent to the printer server theclient requests the printer server to stop the printjob. This is shownin FIG. 13c wherein the WPP client 1001 sends a denotedWPP_End_Print_Req message 1311 to the WPP server 1002. That this isapprehended by the printer server is reported e.g. in a denoted WPPEnd_Print Rsp message 1312 sent to the WPP client 1001.

[0124] After performing one or more printjobs or if a break of theprintjob is requested, the client requests a disconnection of a sessiondefined by the session identifier. Depicted in FIG. 13d, this request isperformed by e.g. sending a denoted WPP_Disconnect_Req message 1313 fromthe WPP client 1001 to the WPP server 1002 and a response, whether thedisconnection is granted or not, is sent in the opposite direction in adenoted WPP_Disconnect_Rsp message 1314.

[0125] When the session is disconnected the WPP client 1001 and the WPPserver 1002 stops sending WPP_Keep_Alive messages.

[0126]FIG. 14 shows a second sub-scenario of a successful printing ofone printjob when the printer is out of paper. Negotiation has beenperformed, a connection is established and keep alive messages are sentas described above though not visible in FIG. 14. The WPP client 1001has requested the WPP server 1002 to start the printjob in a message,e.g. a denoted WPP_Start_Print_Req message 1401, which is respondedsuccess to in a message, e.g. a denoted WPP_Start_Print_Rsp message1402. When the WPP client 1001 has requested the WPP server 1002 toprint data included in a number of messages, e.g. denotedWPP_Print_Data_Req messages 1403, 1404, being acknowledged by the WPPserver 1002 in a message, e.g. a denoted WPP_Print Data_Ack message1405, the printer is out of paper. The printer server then has to reportthis to the client. This can be performed by the WPP server 1002 sendinga message, e.g. a denoted WPP_Status_Ind message 1406, indicating thatthe printer is out of paper to the WPP client 1001. The message isinterpreted by the wireless printer protocol and reported to the user ofthe processing unit, e.g. by presenting a note on the PC screen. Themessage is obtained by a user of the processing unit including theclient, who refills the printer. The printer server then reports thatthe printer is refilled to the WPP client 1001 by sending a message,e.g. a denoted WPP_Status_Ind message 1407. The last received denotedWPP_Print_Data_Ack message 1405 defines where to continue the printingby sending messages, e.g. denoted WPP_Print_Data_Req messages 1408, 1409from the WPP client 1001 to the WPP server 1002. The printer will throwdata if already printed or if a part of it has been printed. Theprinting process then continues as described above. FIG. 15 shows athird sub-scenario of a successful printing of one printjob when the ACLconnection is disconnected. Negotiation has been performed, a connectionis established and keep alive messages are sent as described abovethough not visible in FIG. 15. The WPP client 1001 has requested the WPPserver 1002 to start the printjob in a message, e.g. a denotedWPP_Start_Print_Req message 1501, which is responded success to in amessage, e.g. a denoted WPP_Start_Print_Rsp message 1502. When the WPPclient 1001 has requested the WPP server 1002 to print data included ina number of messages, e.g. WPP_Print_Data_Req messages 1503, 1504, theACL connection is disconnected, indicated by HCI. The Keep Alive Timeris stopped by the WPP client 1001.

[0127] A reconnection of the session is required because it is possiblefor another client to start a printjob during ACL-disconnected. Asession identity is used to identify the different WPP entities. Ifanother job is ongoing the server will not accept the reconnection. Thetime the server will wait for the reconnection has to be handled by areconnection timer. If the timer times out the ongoing job will beflushed. After creating a new ACL-connection a reconnection of thesession is requested. This can be performed by the WPP client 1001 bysending a message, e.g. a denoted WPP_Reconnect_Req message 1506requesting a reconnection of the session defined by the sessionidentifier. A response according to whether the reconnection is grantedor not is sent in a message, e.g. a denoted WPP_Reconnect_Rsp message1507. In this example it is granted. The WPP Keep Alive timer is startedagain. The last received denoted WPP_Print_Data_Ack message 1505 defineswhere to continue the printing by sending messages, e.g. aWPP_Print_Data_Req messages 1507, 1508 from the WPP client 1001 to theWPP server 1002. The printer server will throw data if already printedor if the packet is detected to be a retransmission. The printingprocess then continues as described above.

[0128] The present invention is not limited to the above-describedpreferred embodiments. Various alternatives, modifications andequivalents may be used. Therefore, the above embodiments should not betaken as limiting the scope of invention, which is defined by theappendant claims.

1. A method for printing a document in a data communications system, thesystem including a processing unit including a printer client (1001) anda printer including a printer server (1002), the processing unit and theprinter using for communication between each other a wireless printerprotocol, the Bluetooth protocol stack and air interface, the Bluetoothprotocol stack including a wireless printer protocol and a Logical LinkControl and Adaptation Protocol (L2CAP), the method including the stepsof: establishing (701) a bi-directional wireless asynchronousconnection-less (ACL) connection between the processing unit and theprinter by means of the printer protocol calling the L2CAP requestingthe connection and the L2CAP creating the connection; establishing (702)a connection for one or more printjobs between the printer client (1001)and the printer server (1002); negotiating (703) configurationparameters between the printer client (1001) and the printer server(1002); sending (704) keep alive messages frequently from the printerclient (1001) to the printer server (1002) and from the printer server(1002) to the printer client (1001); starting (705) a print job; sending(706) the print data from the processing unit to the printer; stopping(707) the print job; and closing (708) the connection between theprocessing unit and the printer.
 2. The method according to claim 1,comprising the further step to be taken before the step of establishing(701) a bi-directional wireless ACL connection: selecting a printeramong a number of available printers.
 3. The method according to claim2, wherein the step of selecting a printer is performed by using theDevice Discovery Protocol.
 4. The method according to any of theprevious claims, comprising the further step to be taken before the stepof establishing (701) a bidirectional wireless ACL connection: obtainingan address of a printer.
 5. The method according to claim 4, wherein thestep of obtaining an address of a printer is performed by using theDevice Discovery Protocol.
 6. The method according to claim 5, whereinthe establishing a connection for one or more printjobs is performed bysending a connection request message (1003) from the printer client(1001) to the printer server (1002).
 7. The method according to claim 6,wherein the establishing a connection for one or more printjobs isperformed by responding upon the request whether the connection wassuccessful or not, in a response message (1004) sent from the printerserver (1002) to the printer client (1001).
 8. The method according toany of the previous claims, wherein the step of negotiatingconfiguration parameters (503), between the printer client (1001) andthe printer server (1002), is performed by the printer client (1001)requesting configuration in a message (1101) sent to the printer server(1002), the message including no new options, if printer client (1001)uses default values.
 9. The method according to any of the previousclaims, wherein the step of negotiating configuration parameters (503),between the printer client (1001) and the printer server (1002), isperformed by the printer client (1001) requesting configuration in amessage (1103) sent to the printer server (1002), the message includinga suggestion of configuration options.
 10. The method according to claim9, wherein said configuration request is responded to by the printerserver (1002) in a message (1102, 1104, 1106) indicating whether theconfiguration options in the configuration request are supported by theprinter server (1002) or not.
 11. The method according to claim 10,including the further step, if the configuration request respondsfailure; sending a further configuration request message (1105, 1109)from the printer client (1001) to the printer server (1002), the messageincluding suggestion of configuration options which differs from earliersuggestions of configuration options.
 12. The method according to any ofthe previous claims, comprising the further step to be taken after thestep of negotiating configuration parameters (503): sending a setattribute request message (1201) from the printer client (1001) to theprinter server (1002) the message comprising a coding table concerning anegotiated coding type.
 13. Method according to claim 12, comprising thefurther step of: the printer server (1002) loading the coding table bymeans of said received set attribute request message (1201).
 14. Methodaccording to claim 13, comprising the further step of: sending aresponse whether the loading of the coding table was successful or notin a message (1202) from the printer server (1002) to the printer client(1001).
 15. The method according to any of the previous claims, whereina keep alive timer is implemented in the printer client (1001) and inthe printer server (1002), comprising the further step of: starting thekeep alive timer each time a valid message is received from the remoteendpoint.
 16. The method according to claim 15, wherein said keep alivetimer expires, comprising the further step of: closing the connection.17. The method according to any of the previous claims, wherein the stepof starting a print job (505) is performed by the printer client (1001)requests the printer server (1002) to start a printjob in a requestmessage (1305).
 18. The method according to claim 17, wherein said startprintjob request message (1305) is received and confirmed by the printerserver (1002), the confirmation sent in message (1306) to the printerclient (1001).
 19. The method according to any of the previous claims,wherein the step of sending the print data from the processing unit tothe printer (506), is performed by requesting the printer server (1002)to print data sent in a number of messages (1307, 1308, 1310).
 20. Themethod according to claim 19, comprising the further step to be takenafter the printer server (1002) have received a previous decided numberof print data request messages: sending an acknowledgement message(1309) from the printer server (1002) to the printer client (1001). 21.The method according to any of the previous claims, comprising thefurther step to be taken if the printer runs out of paper: indicatingthat the printer is out of paper in a message (1406) sent from theprinter server (1002) to the printer client (1001).
 22. The methodaccording to claim 21, comprising the further step to be taken when theprinter is refilled: indicating that the printer is refilled in amessage (1407) sent from the printer server (1002) to the printer client(1001).
 23. The method according to claim 22, comprising the furtherstep to be taken after the printer client (1001) has received anindication message (1407) that the printer is refilled: continuing theprinting process by continuing to send print data request messages,(1408, 1409) starting with the print data subsequent to the lastreceived print data acknowledgement message (1405).
 24. The methodaccording to any of the claims, wherein the ACL connection isdisconnected during printing, the method comprising the further step of:stopping the keep alive timer.
 25. The method according to claim 24,wherein a new ACL connection is created comprising the further step of:requesting a reconnection of the session defined by the sessionidentifier in a message (1506) sent from the printer client (1001) tothe printer server (1002).
 26. The method according to claim 25,comprising the further step of: sending a response according to whetherthe reconnection is granted or not in a message (1507) from the printerserver (1002) to the printer client (1001).
 27. The method according toclaim 26, comprising the further step to be taken after the printerclient (1001) has received a granted reconnection response: continuingthe printing process by continuing to send print data request messages(1508, 1509), starting with the print data subsequent to the lastreceived print data acknowledgement message (1505).
 28. The methodaccording to any of the previous claims, wherein the step of stoppingthe print job (707), is performed by, after sending all data to beprinted to the printer server (1002), sending a request to stop theprintjob in a message (1311)from the printer client (1001) to theprinter server (1002).
 29. The method according to claim 28, comprisingthe further step to be taken after the printer server (1002) hasreceived a request to stop the printjob; sending a response message(1312), comprising a confirmation that this is apprehended, from theprinter server (1002) to the printer client (1001).
 30. The methodaccording to any of the previous claims, wherein the step of closing theconnection between the processing unit and the printer (708) isperformed by the printer client (1001) requesting a disconnection of thesession defined by the session identity in a message (1313) sent to theprinter server (1002).
 31. The method according to claim 30, wherein theprinter server responses to whether the disconnection was granted ornot, in a response message (1314) sent from the printer server (1002) tothe printer client (1001).
 32. The method according to any of theprevious claims, comprising the further step to be taken after the stepof closing the connection between the processing unit and the printer(708): stopping the sending of keep alive messages.
 33. A computerprogram product directly loadable into the internal memory of a digitalcomputer within a processing unit or printer in a communication system,comprising the software code portions for performing the steps of any ofthe claims 1-32, when said product is run on a computer.
 34. A computerprogram product stored on a computer usable medium, comprising readableprogram for causing a computer within a processing unit or printer in acommunication system, to control an execution of the steps of any of theclaims 1-32.
 35. An entity (501) included in a Processing unit (402),the entity includes a Bluetooth protocol stack comprising a Logical LinkControl and Adaptation Protocol (L2CAP) characterised in that theBluetooth protocol stack further comprises a wireless printer protocol,said printer protocol comprising a printer client which communicates(803) with a printer server, included in a printer (403), by means ofthe Bluetooth protocol stack and air interface, the entity (501) furthercomprises: an establishing device (502) arranged for establishing abi-directional wireless ACL connection to the printer (403) by callingthe L2CAP requesting the connection; an establishing device (503)arranged for establishing a connection for one or more printjobs anegotiating device (504) arranged for negotiating configurationparameters with a printer server within the printer (403); a sendingdevice (509) arranged for sending keep alive messages frequently to theprinter server ; a starting device (513) arranged for starting a printjob; a sending device (515) arranged for sending the print data to theprinter server; a stopping device (520) arranged for stopping the printjob; and a closing device (522) arranged for closing the connectionbetween the processing unit (402) and the printer (403).
 36. The entity(501) according to claim 35, characterized by comprising a sendingdevice arranged for sending a connection request message from theprinter client to the printer server.
 37. The entity (501) according toany of the claims 35-36 wherein when negotiating configurationparameters, the printer client uses default values, characterised bycomprising a sending device (505) arranged for sending a configurationrequest message to the printer server, the message including no newoptions.
 38. The entity (501) according to any of the claims 35-37,characterised by comprising a sending device (506) arranged for sendinga configuration request message to the printer server, the messageincluding a suggestion of configuration options.
 39. The entity (501)according to any of the claims 35-38, characterised by comprising asending device (507) arranged for sending a further configurationrequest to the printer server, the message including suggestion ofconfiguration options which differs from earlier suggestions ofconfiguration options.
 40. The entity (501) according to any of theclaims 35-39, characterised by comprising a sending device (508)arranged for sending a set attribute request message to the printerserver, the message comprising a coding table concerning a negotiatedcoding type.
 41. The entity (501) according to any of the claims 35-40,characterised in that a keep alive timer (510) is implemented in theprinter client.
 42. The entity (501) according to claim 41,characterised by comprising a starting device (511) arranged forstarting the keep alive timer (510) each time a valid message isreceived from the printer (403).
 43. The entity (501) according to claim42, characterised by comprising a closing device (512) arranged forclosing the connection between the printer client and the printerserver, when the keep alive timer(510) expires.
 44. The entity (501)according to any of the claims 35-43, characterised by comprising asending device (514) arranged for sending a request message to theprinter server comprising a request to start a printjob.
 45. The entity(501) according to any of the claims 35-44, characterised by comprisinga sending device (516) arranged for sending a number of request messagesto the printer server, the messages comprising print data.
 46. Theentity (501) according to any of the claims 35-45, wherein a refill ofpaper has broken a printing process, characterised by comprising acontinuing device (517) arranged for continuing the printing process bycontinuing to send print data request messages to the printer server,starting with the print data subsequent to the last received print dataacknowledgement message.
 47. The entity (501) according to claim 41,characterised by comprising a stopping device (518) arranged forstopping the keep alive timer when the ACL connection is disconnectedduring a printing process.
 48. The entity (501) according to any of theclaims 35-47, wherein a new ACL connection is created to the printerafter a break, characterised by comprising a requesting device (519)arranged for requesting a reconnection of a session defined by thesession identifier in a message sent to the printer server.
 49. Theentity (501) according to claim 48, wherein a granted reconnectionresponse message is received, characterised by comprising a continuingdevice (517) arranged for continuing the printing process by continuingto send print data request messages to the printer server, starting withthe print data subsequent to the last received print dataacknowledgement message.
 50. The entity (501) according to any of theclaims 35-49, wherein all data to be printed is sent to the printercharacterised by comprising a sending device (521) arranged for sendinga message to the printer server, the message comprising a request tostop the printjob.
 51. The entity (501) according to any of the claims35-50, characterised by comprising a sending device (523) arranged forsending a message to the printer server, the message comprising arequest to disconnect a session identified by a session identity. 52.The entity (501) according to any of the claims 35-51, characterised bycomprising a stopping device (524) arranged for stopping the sending ofkeep alive messages after closing a connection between the printerclient and the printer server.
 53. A printer entity (601) included in aPrinter (403), the printer entity (601) including a Bluetooth protocolstack comprising a Logical Link Control and Adaptation Protocol (L2CAP)characterised in that the Bluetooth protocol stack further includes awireless printer protocol, said printer protocol comprising a printerserver which communicates with a printer client, included in aprocessing unit (402), by means of the wireless printer protocol, theBluetooth protocol stack and air interface, the printer entity (601)further comprises: a negotiating device (605) arranged for negotiatingconfiguration parameters with a printer client within the processingunit; a sending device (609) arranged for sending keep alive messagesfrequently to the printer client; a starting device (612) arranged forstarting a print job; a receiving device (614) arranged for receivingprint data from the printer client; and a stopping device (620) arrangedfor stopping the print job.
 54. The printer entity (601) according toclaim 53 characterised in comprising a responding device (604) arrangedfor responding upon a connection request whether the connection issuccessful or not, in a response message sent to the printer client. 55.The printer entity (601) according to any of the claims 53-54characterised in comprising a responding device (606) arranged forresponding upon a configuration request whether the configurationoptions in the configuration request are supported by the printer serveror not.
 56. The printer entity (601) according to any of the claims53-55 characterised in comprising a loading device (607) arranged forloading a coding table sent from the printer client.
 57. The printerentity (601) according claim 56 characterised in comprising a sendingdevice (608) arranged for sending a response whether the loading of thecoding table was successful or not to the printer client.
 58. Theprinter entity (601) according to any of the claims 53-57, characterisedin that a keep alive timer (610) is implemented in the printer server.59. The printer entity (601) according to claim 58, characterised bycomprising a starting device (611) arranged for starting the keep alivetimer each time a valid message is received from the printer.
 60. Theprinter entity (601) according to any of the claims 53-59, characterisedin comprising a confirming device (613) arranged for confirming a startprintjob request message sent to the printer client.
 61. The printerentity (601) according to any of the claims 53-60, characterised incomprising a sending device (615) arranged for sending anacknowledgement message to the printer client after receiving a previousdecided number of print data request messages.
 62. The printer entity(601) according to any of the claims 53-61, characterised in comprisingan indicating device (616) arranged for indicating, in a message sent tothe printer client, that the printer is out of paper, if the printerruns out of paper.
 63. The printer entity (601) according to any of theclaims 53-62, characterised in comprising an indicating device (617)arranged for indicating, in a message sent to the printer client, thatthe printer is refilled, when the printer is refilled.
 64. The printerentity (601) according to any of the claims 53-63, characterised bycomprising a stopping device (618) arranged for stopping the keep alivetimer when an ACL connection to the processing unit is disconnectedduring a printing process.
 65. The printer entity (601) according to anyof the claims 53-64, characterised in comprising a sending device (619)arranged for sending a response message to the printer client, accordingto whether a reconnection request is granted or not.
 66. The printerentity (601) according to any of the claims 53-65, characterized incomprising a sending device (621) arranged for sending a responsemessage, after the printer server has received a request to stop theprintjob, the message comprising a confirmation that this is apprehendedand is sent to the printer client.
 67. The printer entity (601)according to any of the claims 53-66, characterised in comprising asending device (622) arranged for sending a response message to theprinter client, according to whether a disconnection request is grantedor not.
 68. The printer entity (601) according to any of the claims53-67, characterised in comprising a stopping device (623) arranged forstopping the sending of keep alive messages after the connection to theprinter client is closed.
 69. Communications system (401) characterisedby comprising a processing unit (501) according to any of the claims35-52 and a printer entity (601) according to any of the claims 53-68.